home *** CD-ROM | disk | FTP | other *** search
- 40Hex Number 6 Volume 2 Issue 2 File 009
-
- -=[ The 'McAfee scan' viral footprint codes ]=-
-
- -or-
-
- /*******************************************/
- /* A fool and his scanner, can part a user */
- /* from his hard earned money. */
- /*******************************************/
-
- - written by -
- GodNet Raider
- - of -
- The CyberUnderground
-
-
- Thrown into 40Hex by DecimatoR
- from Usenet alt.security
-
- -=[ "Information is the greatest weapon of power to the modern wizard." ]=-
-
- ]----------------------------------------------------------------------------[
-
- Introduction:
- -------------
-
- Recently I began to wonder about the usefulness of 'virus scanners'
- and what if any difference do they have with a simple text/hex search
- program (like nortons filefind/ts). An if there was no real DIFFERENCE,
- how secure is the system that used them.
-
- Problems with scanning:
- -----------------------
-
- The first question I had to ask was, What does a 'virus scanner' actually
- look for? Does it only look for one string of codes or several at different
- places in the file?
-
- To answer this question I called a local BBS an dl'ed McAfee's
- scan3.7v64 (to evaluate and after my tests, it was erased for its lack of
- offering any real protection). Then I went to my archives to retrieve some
- viruses I have experimented with in the past (of which where Jerusalem B and
- Dark Avenger).
-
- I ran scan to verify that the virus files where viruses (3 of which did
- not set off any alarm even tho there was a listing in the documentation for
- them, so I removed them from the test). Then using a sector editor looked at
- the source for the McAfee asso. scan3.7v64 (here after know just as scan64)
- to find that the footprint information was encoded. Needless to say this did
- not stop me (for the sake of those who are into the tech aspects of things,
- the actual method used to get the codes are included at the end of the
- article with the codes found), It took less than an hour to get the codes I
- was looking for (without disassembling the code but by looking into the
- memory allocated to the program).
-
- What I found out was scan was just a simple hex searcher (that kept
- its data locked up till needed). It could also be fooled by any program
- that contained the same hex string as a real virus (this was proved when
- , using a sector editor, I added the scan64 footprint for the Jerusalem B
- into the top of a text file (a place this code would never show up in a real
- infection) then renamed it to *.com; scan64 reported it as infected).
-
- Once the codes where obtained, using debug directly on a virus file,
- I was able to mutate the virus to no longer be detectable by scan64 without
- destroying the integrity of it. For the virus was still able to infect files,
- and scan64 could no longer track it. I was still able to track and control it
- using norton's filefind, diskmon, diskedit, and (of course) DOS erase.
-
- So it seems my question was answered. Some 'virus scanners' just scan
- for a single string of hex character. This is fine if viruses NEVER changed
- or programs would NEVER use code similar to what a virus would (the smaller
- the footprint string the bigger the chance of mistaken alarms). For if
- a 'virus scanner' programer just keeps making a new release each time there
- is a new virus (an I will not get into the morality of charging customers
- the full price of an software upgrade rather than allowing them to buy/dl
- new footprint data files as they become available) for the program will
- eventually grow to unwealdable sizes. An it should be noted there are other
- programs that may do the same job faster, more upward compatibility, and
- you may already have them on hand.
-
- a possible solution:
- --------------------
-
- One thing that I think is a good idea is when a program allows users
- to add new footprint data to it (like nortons' virus package). For now
- users don't need to buy new releases for detection of viruses they may not
- get/be able to detect. Instead for the cost of a call to a support bbs (part
- of the original software agreement?) the user can get new data as it becomes
- available or when they fine a new one on their system they can immediately
- add the new footprint rather than wait for the next version to be released.
-
- Method used to obtain footprints:
- ---------------------------------
-
- After finding the data I was looking for was encoded I thought, How can
- I get the data I wanted for my tests?
-
- Disassembling was out, not for any MORAL reason but, for the time
- involved. So I thought it must have to decode the data for it's own use
- and to save time it would do it all before the scan rather than slow the
- process down by doing a full decode. So I needed to look at the memory
- image of the running program. Thanks to DOS 5.0 and dosshell I was able to
- do this.
-
- After spawning the scan task under the dos shell I used alt-tab to
- swap back to the shell. Once back in the shell I used the shell commands to
- copy the